Modernly, the use of PCs (personal computers), including so-called laptop and notebook computers, is increasingly common and the computers themselves are ever more powerful and complex. A persistent problem is the unduly long elapsed time between the moment of power-on and the time when the PC has become ready for user stimulus and/or to initiate useful work.
Intel® Corporation first defined EFI (Extensible Firmware Interface) as the programming interface exposed by firmware to O/S (operating system); former comparable firmwares were not sufficiently portable nor scalable to Intel's CPU (Central Processor Unit) IA64 architecture. A first implementation of the EFI interface became known as Tiano, which Intel® Corporation offered under license via a web site. The UEFI Forum (Unified EFI Forum), a trade group, secured architectural control over EFI (and derivatives thereof) under a new name—UEFI, with a right to support and extend. The UEFI Forum documents and specifies the UEFI interface.
The PIWG (Platform Initialization Working Group) of the UEFI Forum provides a common internal framework for Silicon and platform drivers, so that a common understanding of the roles and methods used by Silicon and platform drivers is developed by implementers of UEFI firmware stacks together with the providers of the Silicon and platform drivers.
The UEFI and related standards provide richness, but fail to sufficiently address significant specific areas of concern including:                Quality of board bring-up user experience        Quality of BIOS customization experience        Duration of system bootloading and platform initialization time        Level of reliability        Level of compatibility with Intel's Foundation Core (also known as Foundation for short and a part of Tiano)        Scope for platform innovation by BIOS (basic input-output system) vendors and partners and customers thereof.        
These attributes are described in the current version of SCT (SecureCore Tiano™) System Overview published by Phoenix® Technologies Ltd. Adequately addressing all of these areas of concern requires innovation above and beyond what is described in UEFI and PIWG standards. However, innovation needs to be at least backwards compatible with those same standards so as not to lose benefits of compliance therewith.
The EFI/UEFI environments provide for DXE (Driver Execution Environment) firmware running in a limited execution environment with a fixed control policy. A sole means of communication between drivers is the so-called Protocol, a means for drivers to publish pointers to internal routines and data so that other drivers may call and exploit them. Drivers, also known as device drivers are well-known in the computing arts. Although running in protected mode, with 32-bit or 64-bit addressability, the DXE environment implements drivers as connected islands of functional capabilities.
This environment relies on dependency expressions of protocols exposed by DXE drivers, and upon a schedule of DXE drivers to be loaded in a desirable order. Once loaded, DXE drivers are run once, publishing protocols as necessary, so that they might be called again only when their services are requested through published protocols. Limited services are provided by the Foundation for a DXE Driver to gain control on a timer tick, as well as being notified when an O/S loads or has finished loading. Functionality is thereby limited, perhaps unduly limited in view of the specific areas of concern previously mentioned. UEFI lacks a structural framework for execution that is sufficiently flexibly adaptable to problems presented in practical embodiments.
However, UEFI Specification(s) offer considerable richness by making it possible to combine drivers together into stacks in many different ways to form new compound capabilities. In this way UEFI compliant products may contemplate taking on a large problem space for the future.
While UEFI's protocols are well-defined, the execution vehicles providing support for drivers that implement these protocols in the native EFI environment is relatively primitive. There exists a need to provide a more pragmatic extension of the Foundation that provides modern programming paradigms while remaining compatible with existing EFI/UEFI practice and especially with unmodified drivers for a smooth transition to exploitation of the improved capabilities.
A significant advantage of embodiments of the invention over previously developed solutions is that it becomes possible to make improvements by implementing execution parallelism and/or associated time-sharing within a DXE phase of computer loading and initialization.